xen/sched: fix latent races accessing vcpu->dirty_cpu
The dirty_cpu field of struct vcpu denotes which cpu still holds data
of a vcpu. All accesses to this field should be atomic in case the
vcpu could just be running, as it is accessed without any lock held
in most cases. Especially sync_local_execstate() and context_switch()
for the same vcpu running concurrently have a risk for failing.
There are some instances where accesses are not atomically done, and
even worse where multiple accesses are done when a single one would
be mandated.
Correct that in order to avoid potential problems.
Add some assertions to verify dirty_cpu is handled properly.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>